As mobile computing systems have become more and more the common, the number of Wi-Fi enabled devices and Wi-Fi networks has also increased. A Wi-Fi enabled device such as a personal computer, videogame console, smart phone, or digital audio player, can connect to the Internet, or other cloud, when within range of a wireless network. Currently, the coverage of one or more access points, also called “hotspots” can comprise an area as small as a few rooms in a private residence or as large as many square miles. Wi-Fi can provide public access at Wi-Fi hotspots that is free of charge, or by subscription to various commercial services, and/or as provided on a “pay as you” use plan.
One device currently used in connection with Wi-Fi networks is the “captive portal”. The captive portal technique forces an HTTP client on a network to a special captive portal webpage, typically not the webpage requested, for authentication and/or payment purposes prior to providing access to the Internet, or other cloud, and the requested webpage. Typically, a captive portal turns a web browser into an authentication device. This is done by intercepting all packets or ports, until the user opens a browser and tries to access the Internet, at which time the browser is redirected to a captive portal webpage which may then require authentication and/or payment information prior to providing access to the desired webpage. In some cases, the browser is redirected to the captive portal webpage in order to force the user to accept, or decline to accept, licensing terms or other terms of use.
Given that captive portals are now so prevalent, and that captive portals redirect browsers to captive portal webpages that require user input and/or authentication, it is often helpful, and sometimes critical, to detect the presence of a captive portal and/or whether a user is “in” or “out” of a captive portal.
For instance, some hosted Web security services, such as the Symantec Hosted Services Web Security system, available from Symantec, Inc., of Mountain View, Calif., use web proxy servers, or other intervening computing systems, to redirect traffic to a security cloud in order to enforce policies and scan contents. However, if a roaming user is in a captive portal, this traffic should not be redirected to the cloud because the cloud does not know how to, and cannot, access the local captive portal webpages and/or provide authentication data. Of course, if the user is out of a captive portal, the traffic should be redirected to the security cloud immediately to secure the desired protection.
In the example above, the hosted web security service is temporarily disabled in the event of a captive portal; consequently, it is highly desirable to have a reliable captive portable detection system in order to enforce web security policies for roaming users. This is particularly true since a false positive result may expose the user to various security risks, while a false negative result may unnecessarily prevent the user from taking advantage of some Wi-Fi hotspots.
Currently, in some instances, an external web server is used as an observer in an attempt to detect captive portals. However, currently, captive portal detection methods typically send out a single HTTP/HTTPS request and the response is then analyzed. However, these currently available single HTTP/HTTPS request methods and systems are often not reliable because, for example, the end user computing system typically assumes a “success” response is from the observer web server, however, it can actually come from captive portal. In addition, since currently available single HTTP/HTTPS request systems always include an HTTPS component, they are often expensive to implement, in terms of lag time, processor cycles, and other hardware usage, because HTTPS itself is a relatively “heavy”, processor intensive, and “expensive”, mechanism. In addition, currently available single HTTP/HTTPS systems are often inaccurate because they can only detect either HTTP or HTTPS captive portals, but are unable to detect both HTTP and HTTPS captive portals.